Contact centers, such as Automatic Call Distribution or ACD systems, are employed by many enterprises to service customer contacts and non-media interactions or activities (i.e., one or more elements within a business process). Media and non-media interactions are collectively referred to as “work items”. A typical contact center includes a switch and/or server to receive and route incoming packet-switched and/or circuit-switched interactions and one or more resources, such as human agents and automated resources (e.g., Interactive Voice Response (IVR) units), to service the incoming interactions.
A workflow routing engine directs work items to various agents based on algorithms and predetermined criteria. Conventionally, the ACD's controller identifies all predefined interaction-handling skills of the agent and delivers to the agent the interaction that best matches the agent's highest-priority skill. The criteria may be customer-specifiable (i.e., programmable by the contact center operator) via a call vectoring capability or through complex programmable workflows that select the “optimal” agent based on various parameters. Normally predetermined criteria include agent skills, interaction requirements, media type and availability of an agent, expected contact wait time, etc.
In multi-media contact centers servicing a wide variety of contact types, different routing and queuing algorithms are commonly used for different media types to increase the accuracy and speed with which such contacts are handled. Unlike voice calls, when a document-based contact (e.g., email, fax, Short Message Service or SMS message, instant message, etc.) is received, the contact's text may be analyzed via natural language processing to determine the topic and then routed to an “optimal” agent (e.g., Subject Matter Expert or SME) for that topic. A voice call, in contrast, is analyzed by the time intensive interaction of an automated resource, specifically an IVR, with the customer. When a customer sends in an email with a question to a contact center, they are not always concerned with receiving immediate feedback. In contrast, when a customer calls into a contact center with a question they almost certainly do not want to wait for days to be attended to. As a consequence, the rules regarding how these two different media types are handled vary significantly. When a call comes into a call center, the amount of time a call has waited is often the most important parameter that determines where that contact is sent. However, when an email comes into a contact center, matching of agent skills with contact requirements is commonly the most important parameter, and the amount of time that contact sits in the queue is not as high a priority.
Exemplary multi-media contact center work item routing parameters include routing an interaction escalated by a customer (e.g., email) to an agent who has handled a previous escalated interaction from the same customer, but over different media (e.g., voice); routing an interaction (e.g., a first email from a first customer) to an agent who has previously handled an interaction that is part of the same thread (e.g., the first email is a reply to a second email sent by a first agent, which in turn was a response to a third email that was the first customer's initial email into the contact center); and routing an interaction based on the available agent's skill sets. As used herein, “escalation” is the process of generating an incoming interaction.
Commonly, the only conditions that result in an interaction not being delivered to an agent are first that there are not available agents for that escalated media type (in which case the interaction is queued indefinitely to be routed to the next available agent) and second that there are no interactions in the contact center to be delivered.
There are many occasions when the workflow routing engine chooses an agent who cannot handle a given interaction or set of interactions, usually because the workflow routing engine is making decisions with a limited amount of information (the relatively-easy-to-determine parameters). When this situation arises, the agent is typically required to put the interaction back into the queue, and the workflow routing engine is forced to re-route the contact or find another agent who may or may not be able to handle the given interaction. Every time an interaction is re-routed from agent to agent, precious bandwidth and contact center capacity is utilized, plus the customer has to wait that much longer to have their interaction serviced. It is also not uncommon to have a single interaction be re-routed multiple times in a typical contact center. These unfortunate delays pose a serious inconvenience to any customer who has escalated an interaction, especially a customer who has escalated a real time interaction.
In current call centers, every time the workflow routing engine chooses a new agent for a re-routed interaction, it does so using only the information it received from the initial IVR or human agent exchange. The only thing that the workflow routing engine knows during a re-route is that it should not send that particular interaction back to the same agent. This negative limitation is the only information the workflow routing engine gains during a re-route. The workflow routing engine can only make a routing decision as “smart” as the information it has available to it. This information typically does not change once an interaction or set of interactions has been assigned to a first servicing agent, thus re-routes and transfers are completed with basically the same information that was available to the workflow routing engine during the first assignment. For this reason, during re-routes and transfers, the workflow routing engine will sometimes assign agents to an interaction(s) who are incapable of servicing that given interaction(s).
In addition, when a second interaction enters the contact center that is similar to the previously re-routed interaction, that interaction sometimes finds itself being assigned by the workflow routing engine to the same agent who has already determined that he cannot handle this type of interaction. The agent is then forced to spend time rerouting interactions of the same type back to the workflow routing engine for additional re-routes. All the while, the customer must wait for an exceptional amount of time until they are finally routed to an agent that can handle their queries. All of these potentially unnecessary re-routes can lead to unhappy customers and frustrated agents.
The following examples illustrate the above-noted contact center inefficiencies. In a first example a customer has escalated a chat to query about an email that they had sent sometime earlier. The customer record in the contact center specifies the chat customer's email id to be customer@address1.com, while the email sent earlier was from another account, customer@address2.com. Since the address2.com account is not part of the customer record, the contact center routing algorithms have no way to detect that this chat escalation is related to the previous email. It may happen that these interactions initially arrive at the same agent's desktop. However, the agent is not a domain expert on the topic associated with the chat and email, so the agent would like to transfer the chat interaction back to another chat queue and would also like to transfer the email interactions back to another email queue. In this scenario, the agent knows that these interactions are related (from the same customer) based on conversations with the customer. Unfortunately, the contact center routing engine has no idea of this relation. If the agent transfers both these interactions, the workflow routing engine may make the mistake of sending the interactions to two different agents. This will lead to a duplication of work in the contact center and result in decreased contact center efficiency.
As another example, an agent has multiple interactions assigned to him/her. In this scenario, assume the interactions include 20 emails and 10 fax interactions. All interactions are from different customers, but some of them have a common topic—that of a home loan application. The agent is a domain expert on car loans, but not home loans. The agent decides to transfer all these home loan application related emails back to the system. Now, the routing engine may not know they are related in intent or purpose, since they are not from the same customer. In this case, the emails may get routed to different agents, when ideally, they should go to just one agent, since they are related, and therefore the agent could deal with all of them quickly and efficiently.
The foregoing examples reveal a number of problems in conventional contact centers. Every contact center confronts situations where the workflow routing engine initially fails to direct the interactions to a capable agent. Transfers and re-routes are common place in all contact centers and every uninformed re-route by the workflow routing engine leads to increased inefficiencies of the contact center as a whole. Workflow routing engines are only as smart as the information they have available to them. They have no way to collect information for an interaction without some other entity providing it to them. Some contact centers have IVR's and other initial information gathering members that can provide fairly easy to acquire information to the contact center. However, these members are limited in that they are only able to gather information for one interaction at a time and can only do so when an interaction enters a contact center. Furthermore, none of the current information collecting members are able to continually update information pertinent to a given interaction during that interaction's existence in the contact center. There is no mechanism available to allow the human agents of a contact center to provide additional “human” intelligence to the workflow routing engine before or during a re-route/transfer.